RADVD.CONF(5)                                                    RADVD.CONF(5)



NNAAMMEE
       radvd.conf  -  configuration  file  of  the router advertisement daemon
       rraaddvvdd

DDEESSCCRRIIPPTTIIOONN
       This file describes the information which is  included  in  the  router
       advertisement (RA) of a specific interface.

       The file contains one or more interface definitions of the form:

       iinntteerrffaaccee name {{
            list of interface specific options
            list of prefix definitions
            list of clients (IPv6 addresses) to advertise to
            list of route definitions
            list of RDNSS definitions
            list of DNSSL definitions
       }};;

       All  the  possible interface specific options are detailed below.  Each
       option has to be terminated by a semicolon.

       Prefix definitions are of the form:

       pprreeffiixx prefix//length {{
            list of prefix specific options
       }};;

       Prefix can be network prefix or the  address  of  the  inferface.   The
       address  of interface should be used when using Mobile IPv6 extensions.

       Special prefix "::/64" is also  supported  on  systems  that  implement
       getifaddrs()  (on  other  systems,  configuration  activation fails and
       radvd exits).  When configured, radvd picks one  non-link-local  prefix
       assigned  to  the  interface  and  starts  advertising it.  This may be
       applicable in  non-6to4  scenarios  where  the  upstream  prefix  might
       change.   This  option  is  incompatible with Base6to4Interface option.
       AdvRouterAddr option is always enabled when this configuration is used.

       All  the  possible  prefix  specific options are described below.  Each
       option has to be terminated by a semicolon.

       Decimal values are allowed only for MinDelayBetweenRAs, MaxRtrAdvInter-
       val  and  MinRtrAdvInterval.   Decimal  values should be used only when
       using Mobile IPv6 extensions.

       Route definitions are of the form:

       rroouuttee prefix//length {{
            list of route specific options
       }};;

       The prefix of a route definition should be network prefix;  it  can  be
       used to advertise more specific routes to the hosts.

       RDNSS (Recursive DNS server) definitions are of the form:

       RRDDNNSSSS ip [ip] [ip] {{
            list of rdnss specific options
       }};;

       DNSSL (DNS Search List) definitions are of the form:

       DDNNSSSSLL suffix [suffix] [suffix] [...] {{
            list of dnssl specific options
       }};;

       By  default  radvd will send route advertisements so that every node on
       the link can use them.  The list of clients (IPv6 address) to advertise
       to,  and  accept  route solicitations from can be configured.  If done,
       radvd does not send send messages to the multicast addresses but to the
       configured  unicast addresses only.  Solicitations from other addresses
       are refused.  This is similar to UnicastOnly but includes periodic mes-
       sages  and  incoming client access configuration.  See examples section
       for a use case of this.

       The definitions are of the form:

       cclliieennttss {
               list of IPv6 addresses
       }};;


IINNTTEERRFFAACCEE SSPPEECCIIFFIICC OOPPTTIIOONNSS
       IIggnnoorreeIIffMMiissssiinngg oonn|ooffff

              A flag indicating whether or not the interface is ignored if  it
              does not exist at start-up.  By default, radvd exits.

              This  is useful for dynamic interfaces which are not active when
              radvd starts or which are dynamically  disabled  and  re-enabled
              during the time radvd runs.

              Current  versions of radvd automatically try to re-enable inter-
              faces.

              Enabling IgnoreIfMissing also quenches certain warnings  in  log
              messages relating to missing interfaces.

              Default: off


       AAddvvSSeennddAAddvveerrtt oonn|ooffff

              A  flag  indicating  whether  or  not  the router sends periodic
              router advertisements and responds to router solicitations.

              This option no longer has to be specified first, but it needs to
              be oonn to enable advertisement on this interface.

              Default: off


       UUnniiccaassttOOnnllyy oonn|ooffff

              Indicates  that  the  interface link type only supports unicast.
              This will prevent unsolicited advertisements  from  being  sent,
              and  will  cause  solicited  advertisements to be unicast to the
              soliciting node.  This option is  necessary  for  non-broadcast,
              multiple-access links, such as ISATAP.

              Default: off


       MMaaxxRRttrrAAddvvIInntteerrvvaall seconds

              The  maximum  time allowed between sending unsolicited multicast
              router advertisements from the interface, in seconds.

              Must be no less than 4 seconds and no greater than 1800 seconds.

              Minimum when using Mobile IPv6 extensions: 0.07.

              For  values  less  than  0.2  seconds,  0.02 seconds is added to
              account for scheduling granularities as specified in RFC3775.

              Default: 600 seconds


       MMiinnRRttrrAAddvvIInntteerrvvaall seconds

              The minimum time allowed between sending  unsolicited  multicast
              router advertisements from the interface, in seconds.

              Must  be no less than 3 seconds and no greater than 0.75 * MaxR-
              trAdvInterval.

              Minimum when using Mobile IPv6 extensions: 0.03.

              Default: 0.33 * MaxRtrAdvInterval


       MMiinnDDeellaayyBBeettwweeeennRRAAss seconds

              The minimum time allowed between sending multicast router adver-
              tisements from the interface, in seconds.

              This applies to solicited multicast RAs.  This is defined as the
              protocol constant MIN_DELAY_BETWEEN_RAS in RFC4861.  MIPv6 rede-
              fines this parameter to have a minimum of 0.03 seconds.

              Minimum when using Mobile IPv6 extensions: 0.03.

              Default: 3


       AAddvvMMaannaaggeeddFFllaagg oonn|ooffff

              When  set,  hosts  use  the administered (stateful) protocol for
              address autoconfiguration in addition to any addresses  autocon-
              figured  using  stateless address autoconfiguration.  The use of
              this flag is described in RFC 4862.

              Default: off


       AAddvvOOtthheerrCCoonnffiiggFFllaagg oonn|ooffff

              When set, hosts use the  administered  (stateful)  protocol  for
              autoconfiguration  of  other (non-address) information.  The use
              of this flag is described in RFC 4862.

              Default: off


       AAddvvLLiinnkkMMTTUU integer

              The MTU option is used  in   router  advertisement  messages  to
              insure  that all nodes on a link use the same MTU value in those
              cases where the link MTU is not well known.

              If specified, i.e. not 0, must not be smaller than 1280 and  not
              greater  than the maximum MTU allowed for this link (e.g. ether-
              net has a maximum MTU of 1500. See RFC 4864).

              Default: 0


       AAddvvRReeaacchhaabblleeTTiimmee milliseconds

              The time, in milliseconds, that a node  assumes  a  neighbor  is
              reachable  after  having  received  a reachability confirmation.
              Used by the Neighbor  Unreachability  Detection  algorithm  (see
              Section 7.3 of RFC 4861).  A value of zero means unspecified (by
              this router).

              Must be no greater than 3,600,000 milliseconds (1 hour).

              Default: 0


       AAddvvRReettrraannssTTiimmeerr milliseconds

              The time, in milliseconds, between retransmitted Neighbor Solic-
              itation  messages.   Used by address resolution and the Neighbor
              Unreachability Detection algorithm (see Sections 7.2 and 7.3  of
              RFC  4861).  A value of zero means unspecified (by this router).

              Default: 0


       AAddvvCCuurrHHooppLLiimmiitt integer

              The default value that should be placed in the Hop  Count  field
              of  the  IP header for outgoing (unicast) IP packets.  The value
              should be set to the current  diameter  of  the  Internet.   The
              value zero means unspecified (by this router).

              Default: 64


       AAddvvDDeeffaauullttLLiiffeettiimmee seconds

              The lifetime associated with the default router in units of sec-
              onds.  The maximum value corresponds to 18.2 hours.  A  lifetime
              of  0  indicates  that  the  router  is not a default router and
              should not appear on the default router list.  The router  life-
              time  applies  only  to  the  router’s  usefulness  as a default
              router; it does not apply to information contained in other mes-
              sage fields or options.  Options that need time limits for their
              information include their own lifetime fields.

              Must be either zero or between MaxRtrAdvInterval and  9000  sec-
              onds.

              Default: 3 * MaxRtrAdvInterval (Minimum 1 second).


       AAddvvDDeeffaauullttPPrreeffeerreennccee llooww|mmeeddiiuumm|hhiigghh

              The  preference  associated  with  the default router, as either
              "low", "medium", or "high".

              Default: medium


       AAddvvSSoouurrcceeLLLLAAddddrreessss oonn|ooffff

              When set, the link-layer address of the  outgoing  interface  is
              included in the RA.

              Default: on


       AAddvvHHoommeeAAggeennttFFllaagg oonn|ooffff

              When  set,  indicates  that  sending  router is able to serve as
              Mobile IPv6 Home Agent.  When set, minimum limits  specified  by
              Mobile  IPv6  are used for MinRtrAdvInterval and MaxRtrAdvInter-
              val.

              Default: off


       AAddvvHHoommeeAAggeennttIInnffoo oonn|ooffff

              When set, Home Agent Information  Option  (specified  by  Mobile
              IPv6)  is  included  in Router Advertisements.  AdvHomeAgentFlag
              must also be set when using this option.

              Default: off


       HHoommeeAAggeennttLLiiffeettiimmee seconds

              The length of time in seconds (relative to the time  the  packet
              is sent) that the router is offering Mobile IPv6 Home Agent ser-
              vices.  A value 0 must not be used.   The  maximum  lifetime  is
              65520 seconds (18.2 hours).  This option is ignored, if AdvHome-
              AgentInfo is not set.

              If both HomeAgentLifetime and  HomeAgentPreference  are  set  to
              their  default values, Home Agent Information Option will not be
              sent.

              Default: AdvDefaultLifetime


       HHoommeeAAggeennttPPrreeffeerreennccee integer

              The preference for the Home Agent sending this Router Advertise-
              ment.   Values  greater  than  0  indicate  more preferable Home
              Agent, values less than 0 indicate less preferable  Home  Agent.
              This option is ignored, if AdvHomeAgentInfo is not set.

              If  both  HomeAgentLifetime  and  HomeAgentPreference are set to
              their default values, Home Agent Information Option will not  be
              sent.

              Default: 0


       AAddvvMMoobbRRttrrSSuuppppoorrttFFllaagg oonn|ooffff

              When  set, the Home Agent signals it supports Mobile Router reg-
              istrations (specified by  NEMO  Basic).   AdvHomeAgentInfo  must
              also be set when using this option.

              Default: off


       AAddvvIInntteerrvvaallOOpptt oonn|ooffff

              When  set,  Advertisement  Interval  Option (specified by Mobile
              IPv6) is included in Router Advertisements.  When  set,  minimum
              limits  specified  by Mobile IPv6 are used for MinRtrAdvInterval
              and MaxRtrAdvInterval.

              The advertisement interval is based on the configured MaxRtrAdv-
              Interval  parameter  except  where  this is less than 200ms.  In
              this case, the advertised interval is ( MaxRtrAdvInterval + 20ms
              ).

              Default: off


PPRREEFFIIXX SSPPEECCIIFFIICC OOPPTTIIOONNSS
       AAddvvOOnnLLiinnkk oonn|ooffff

              When  set,  indicates  that  this prefix can be used for on-link
              determination.  When not set the advertisement makes  no  state-
              ment  about  on-link  or off-link properties of the prefix.  For
              instance, the prefix might be  used  for  address  configuration
              with some of the addresses belonging to the prefix being on-link
              and others being off-link.

              Default: on


       AAddvvAAuuttoonnoommoouuss oonn|ooffff

              When set, indicates that this prefix can be used for  autonomous
              address configuration as specified in RFC 4862.

              Default: on


       AAddvvRRoouutteerrAAddddrr oonn|ooffff

              When  set,  indicates  that  the  address  of  interface is sent
              instead of network prefix, as is required by Mobile IPv6.   When
              set,  minimum limits specified by Mobile IPv6 are used for MinR-
              trAdvInterval and MaxRtrAdvInterval.

              Default: off


       AAddvvVVaalliiddLLiiffeettiimmee seconds|iinnffiinniittyy

              The length of time in seconds (relative to the time  the  packet
              is  sent)  that  the  prefix is valid for the purpose of on-link
              determination.  The symbolic value iinnffiinniittyy represents  infinity
              (i.e. a value of all one bits (0xffffffff)).  The valid lifetime
              is also used by RFC 4862.

              Note that clients will ignore AdvValidLifetime  of  an  existing
              prefix  if  the  lifetime is below two hours, as required in RFC
              4862 Section 5.5.3 point e).

              Note: RFC4861’s suggested default value is significantly longer:
              30 days.

              Default: 86400 seconds (1 day)


       AAddvvPPrreeffeerrrreeddLLiiffeettiimmee seconds|iinnffiinniittyy

              The  length  of time in seconds (relative to the time the packet
              is sent) that addresses generated from the prefix via  stateless
              address  autoconfiguration remain preferred.  The symbolic value
              iinnffiinniittyy represents infinity (i.e.  a  value  of  all  one  bits
              (0xffffffff)).  See RFC 4862.

              Note: RFC4861’s suggested default value is significantly longer:
              7 days.

              Default: 14400 seconds (4 hours)


       BBaassee66ttoo44IInntteerrffaaccee name

              If this option is specified, this prefix will be  combined  with
              the  IPv4 address of interface nnaammee to produce a valid 6to4 pre-
              fix. The first 16 bits of this prefix will be replaced  by  22000022
              and the next 32 bits of this prefix will be replaced by the IPv4
              address assigned to interface nnaammee at  configuration  time.  The
              remaining  80  bits of the prefix (including the SLA ID) will be
              advertised as specified in the configuration file.  See the next
              section for an example.

              If  interface  nnaammee  is  not  available at configuration time, a
              warning will be written to the log and this prefix will be  dis-
              abled until radvd is reconfigured.

              This  option  enables  systems  with  dynamic  IPv4 addresses to
              update their advertised 6to4 prefixes simply by restarting radvd
              or sending a SIGHUP signal to cause radvd to reconfigure itself.

              Note that 6to4 prefixes derived from  dynamically-assigned  IPv4
              addresses  should  be  advertised  with  a significantly shorter
              lifetime  (see  the  AAddvvVVaalliiddLLiiffeettiimmee  and  AAddvvPPrreeffeerrrreeddLLiiffeettiimmee
              options).

              For more information on 6to4, see RFC 3056.

              Default: 6to4 is not used


RROOUUTTEE SSPPEECCIIFFIICC OOPPTTIIOONNSS
       AAddvvRRoouutteeLLiiffeettiimmee seconds|iinnffiinniittyy

              The lifetime associated with the route in units of seconds.  The
              symbolic value iinnffiinniittyy represents infinity (i.e. a value of all
              one bits (0xffffffff)).

              Default: 3 * MaxRtrAdvInterval


       AAddvvRRoouutteePPrreeffeerreennccee llooww|mmeeddiiuumm|hhiigghh

              The  preference  associated  with  the default router, as either
              "low", "medium", or "high".

              Default: medium


RRDDNNSSSS SSPPEECCIIFFIICC OOPPTTIIOONNSS
       AAddvvRRDDNNSSSSPPrreeffeerreennccee integer;

       AAddvvRRDDNNSSSSOOppeenn on||off;

              These features were present in the draft specification but  were
              removed  from RFC5006. They are still accepted in the configura-
              tion but ignored.


       AAddvvRRDDNNSSSSLLiiffeettiimmee seconds||infinity;
              The maximum duration how long the RDNSS  entries  are  used  for
              name  resolution.  A  value  of 0 means the nameserver should no
              longer be used.  The maximum duration how long the RDNSS entries
              are  used for name resolution. A value of 0 means the nameserver
              should no longer be used.  The value, if not 0, must be at least
              MaxRtrAdvInterval.  To ensure stale RDNSS info gets removed in a
              timely fashion, this should not be greater  than  2*MaxRtrAdvIn-
              terval.

              Default: 2*MaxRtrAdvInterval


DDNNSSSSLL SSPPEECCIIFFIICC OOPPTTIIOONNSS
       AAddvvDDNNSSSSLLLLiiffeettiimmee seconds||infinity;
              The  maximum  duration  how  long the DNSSL entries are used for
              name resolution.  A value of 0 means the suffix should no longer
              be  used.  The value, if not 0, must be at least MaxRtrAdvInter-
              val.  To ensure stale DNSSL info gets removed in a timely  fash-
              ion, this should not be greater than 2*MaxRtrAdvInterval.

              Default: 2*MaxRtrAdvInterval


EEXXAAMMPPLLEESS
       interface eth0
       {
               AdvSendAdvert on;
               prefix 2001:db8:0:1::/64
               {
                       AdvOnLink on;
                       AdvAutonomous on;
               };
       };

       It  says  that router advertisement daemon should advertise (AdvSendAd-
       vert on;) the prefix 2001:db8:0:1:: which has a lenght  of  64  on  the
       interface eth0.  Also the prefix should be marked as autonomous (AdvAu-
       tonomous on;) and as on-link (AdvOnLink on;).  All  the  other  options
       are left on their default values.

       To  support movement detection of Mobile IPv6 Mobile Nodes, the address
       of interface should be used instead of network prefix:

       interface eth0
       {
               AdvSendAdvert on;
               prefix 2001:db8:0:1::4/64
               {
                       AdvOnLink on;
                       AdvAutonomous on;
                       AdvRouterAddr on;
               };
       };

       For 6to4 support, include the BBaassee66ttoo44IInntteerrffaaccee option in  each  prefix
       section.  When using a dynamic IPv4 address, set small prefix lifetimes
       to prevent hosts from retaining unreachable prefixes after a  new  IPv4
       address  has been assigned.  When advertising to on a dynamic interface
       (e.g., Bluetooth), skip the interface if it is not active yet.

       interface bnep0
       {
               IgnoreIfMissing on;
               AdvSendAdvert on;

               # Advertise at least every 30 seconds
               MaxRtrAdvInterval 30;

               prefix 0:0:0:5678::/64
               {
                       AdvOnLink on;
                       AdvAutonomous on;
                       Base6to4Interface ppp0;

                       # Very short lifetimes for dynamic addresses
                       AdvValidLifetime 300;
                       AdvPreferredLifetime 120;
               };
       };

       Since  6to4  is   enabled,   the   prefix   will   be   advertised   as
       2002:WWXX:YYZZ:5678::/64, where WW.XX.YY.ZZ is the IPv4 address of ppp0
       at configuration time.  (IPv6  addresses  are  written  in  hexadecimal
       whereas  IPv4  addresses  are  written  in decimal, so the IPv4 address
       WW.XX.YY.ZZ in the 6to4 prefix will be represented in hex.)

       In this specific case, the configuration scripts may send HUP signal to
       radvd  when  taking bnep0 up or down to notify about the status; in the
       current radvd releases, sending HUP is no  longer  mandatory  when  the
       link comes back up.

       interface eth0
       {
               AdvSendAdvert on;
               prefix 2001:db8:0:1::/64
               {
                       AdvOnLink on;
                       AdvAutonomous on;
               };
               clients
               {
                       fe80::21f:16ff:fe06:3aab;
                       fe80::21d:72ff:fe96:aaff;
               };
       };

       This    configuration    would    only    announce    the   prefix   to
       fe80::21f:16ff:fe06:3aab  and  fe80::21d:72ff:fe96:aaff.   Furthermore,
       all RA requests of other clients are denied.

       This  may  come  in  handy  if you want to roll out IPv6 only partially
       because some clients are broken or untested.



FFIILLEESS
       @sbindir@/radvd
       @PATH_RADVD_CONF@
       @PATH_RADVD_PID@
       @PATH_RADVD_LOG@


CCRREEDDIITT
       The description of the different flags and variables is in large  parts
       taken from RFC 4861.


RRFFCCSS
       Narten,  T.,  Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Dis-
       covery for IP Version 6 (IPv6)", RFC 4861, September 2007.

       Thomson, S., Narten, T., T. Jinmei, "IPv6 Stateless Address Autoconfig-
       uration", RFC 4862, September 2007.

       Deering, S., and R. Hinden, "IP Version 6 Addressing Architecture", RFC
       4291, February 2006.

       Conta, A., Deering, S., and M. Gupta "Internet Control Message Protocol
       (ICMPv6)  for  the Internet Protocol Version 6 (IPv6)", RFC 4443, March
       2006.

       Crawford, M., "Transmission of IPv6 Packets  over  Ethernet  Networks",
       RFC 2464, December 1998.

       Carpenter  B.,  K. Moore, "Connection of IPv6 Domains via IPv4 Clouds",
       RFC 3056, February 2001. (6to4 specification)

       Draves, R., D. Thaler, "Default Router  Preferences  and  More-Specific
       Routes", RFC 4191, November 2005.

       Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC
       3775, June 2004.

       Devarapalli, V., Wakikawa, R., Petrescu, A., and  P.  Thubert  "Network
       Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.

       J.  Jeong, S. Park, L. Beloeil, and S. Madanapalli, "IPv6 Router Adver-
       tisement Options for DNS Configuration", RFC 6106, November 2010.


SSEEEE AALLSSOO
       rraaddvvdd(8), rraaddvvdduummpp(8)


BBUUGGSS
       radvd does not support splitting up RAs to  multiple  packets  (RFC4861
       6.2.3 last paragraph).  In practise this limits advertising to ~45 pre-
       fixes on a link, but there is no reason to be able to so.




radvd @VERSION@                   4 Jan 2011                     RADVD.CONF(5)
